1. Field of the Invention
This invention relates to the field of client/server computer environments.
2. Background
In the prior art, client/server environments supporting networked objects rely on a local object request broker process, or ORB daemon, to coordinate requests between a client and an object server. When a client has an object reference, the client attempts to contact a locally running ORB daemon. If there is no ORB daemon running on the local host machine or at a user preset override location, the client cannot access services on the network. There is no mechanism for a pure client, i.e., a client without the support of ORB software, to automatically locate and contact another ORB daemon on the network for the purpose of accessing object services.
Networked Object Environment
In the networked object environment, an object server is a multi-threaded process that controls access to, instantiation of, and deletion of, the methods, data, etc., embodied in the objects within its domain. Objects are self-contained, clearly defined, software modules that encapsulate procedures, such as business practices, and their data. Communicating with each other through carefully defined interfaces, objects allow complex solutions to be constructed similar to the manner in which computers are manufactured from standardized electronic components. Multiple levels of re-use and standardization are made possible, enabling engineers to produce modules, applications, and entire systems that are highly reusable and leveragable.
Networked object technology allows applications access to objects and their shared services anywhere in the network, substantially independent of where the application or object resides. Networked objects also permit individual objects to be updated without the risk of disrupting the application or business process it models, facilitating the graceful, incremental evolution of complex systems. For example, if a new component fails, the component""s predecessor can be re-instated quickly and transparently.
An example of the networked object environment is the CORBA-compliant NEO product family from SunSoft(trademark), which provides for sharing of objects across networks and differing computing platforms.
Consisting of over 500 software vendors, developers, and end user organizations, the Object Management Group (OMG) has developed and continues to develop standards for a common architecture supporting heterogeneous, distributed, object-oriented applications. The OMG Common Object Request Broker Architecture (CORBA) is designed to allow different object systems from multiple vendors to interact with each other on a network. The CORBA specification comprises the following four components:
i) An Object Request Broker (ORB) to manage objects in a networked environment;
ii) Interoperability for ORB-to-ORB communications;
iii) Common Object Services (CORBAservices); and
iv) Mappings for commonly used programming languages.
The Network Object Request Broker (ORB) is a CORBA-compliant network-based software system providing for the location and execution of objects through a standard interface protocol, enabling objects and programs to transparently interact with each other across the network. The NEO ORB is implemented as one or more multi-threaded UNIX processes, providing scalable performance and availability as needed.
To promote heterogeneous object interoperability, the OMG has provided a portable source code reference implementation of the CORBA 2.0 Internet Inter-ORB Protocol to assist software vendors in testing and delivering OMG-compliant products. The Internet Inter-ORB Protocol (Internet IOP) provides a standardized way of connecting ORBs from different CORBA 2.0 compliant vendors, enabling them to communicate with each other. The current Internet IOP is based on TCP/IP protocols.
The OMG CORBAservices definition describes the basic operations required for building distributed systems with objects, such as naming, events, properties, lifecycle and relationship services.
For different object systems to interact, language independence is a concern. The Interface Definition Language (IDL) enables the separation of interface and implementation, allowing object implementation details to change without compromising the plug-and-play qualities of the object. The OMG IDL is a neutral interface definition of an object""s operations, allowing the behavior of the object to be defined in IDL, but accommodating the automated transformation of the interface to the C, C++, Objective C, or Smalltalk languages.
A multi-threaded environment, such as that provided by UNIX, is typically used for supporting networked objects. Threads are subprocesses spawned off of larger processes for performing a certain function, e.g. performing a printing process, acting on a database object, etc. By supporting multiple threads, the system can serve many clients and processes simultaneously. This enables the sharing of objects and services on the network.
In the CORBA environment, an Object Request Broker Daemon process (ORBD) receives object requests, also referred to as method invocations, from the client processes registered to it. The ORB daemon then locates the object on the network, and acts as the interface between the client process and the networked object. In the NEO environment, the ORB daemon may activate a NEO object server to act as a further interface for the object which may be a standard NEO object or, in some instances, a legacy process encapsulated in a NEO shell to perform as a NEO object. The NEO object server acts to instantiate the object as is necessary to respond to the requests forwarded by the ORB daemon.
Networked Object System Block Diagram
FIG. 1 is a block diagram of a CORBA-compliant networked object system. Multiple threads are represented by elements 100-103, where threads 100-101 are threads spawned from a first client process, Client Process 1, and threads 102-103 are threads spawned from a second client process, Client Process N. As indicated in FIG. 1, a single client process can spawn any number of threads. Each of threads 100-103 is linked to Object Request Broker Daemon (ORBD) process 104. ORBD process 104 is in turn linked to a plurality of object servers represented by object server 105 and object server 107. A second ORBD process, ORBD process 110, is further linked to ORBD process 104. ORBD process 110 could also be coupled to further object servers and/or client processes (not shown). Object server 105 is linked to object 106. Object server 107 is linked to objects 108 and 109.
ORBD process 104 receives object requests, such as method invocations in the form of locate requests, from client process threads 100-103, and determines which object server is supporting the appropriate object. If the necessary server is not currently running, the sever s activated and the object is instantiated. Information on the location of the object is returned in response to the locate request, and further requests between the thread and the object are directed by the location information. The same object can be similarly invoked by locate requests from other threads to establish interaction between the object and all applicable threads concurrently.
ORB daemon 110 may provide a gateway for the networked object environment over a large network such as the Internet and/or it may provide cross-platform interaction by providing a platform dependent interface to clients and object servers in its own domain, while providing a standardized interface to ORBD 104.
Object servers 105 and 107 provide access to objects, such as shown by objects 106 and 108-109. Legacy objects, that is those objects comprising stand-alone applications and other objects not originally designed for the networked object environment, are provided with an IDL shell that forms an interface through which the object server can access the functions of the legacy object. A Persistent Store Manager process running in tandem with the ORB daemon keeps track of locks the object server may have on objects, e.g., database objects, to maintain server-exclusive access.
As the network is substantially independent of hardware boundaries, the objects and object servers may reside on the same computer as the client processes and the ORB daemon, or they may reside on separate computers within the network.
Physical Network System Block Diagram
The physical configuration of a network for supporting networked objects is illustrated in FIGS. 2A and 2B. The interaction of two host machines in a network is described with respect to two interactive scenarios. In the first scenario, described with respect to FIG. 2A, both host machines are configured as combination clients and servers, capable of providing object services to each other. Each host machine stores the full software support for client and server functions. In the second scenario, described with respect to FIG. 2B, one host machine is configured as a client, whereas the second host machine is configured as a combination client and server for providing object services to both host machines. The first host machine relies on the second host machine as a remote provider of object services, thus reducing the locally stored software support by excluding server specific software. Software administration needs are therefore reduced.
FIG. 2A illustrates a possible network configuration wherein each host machine has a full installation of networked objects software. A full installation includes executable, machine language binaries for a client application, machine language binaries for the ORB daemon, a library containing networked object support software such as development tools, debugging tools, administration tools, etc., as well as machine language binaries for any objects and object servers to be served from the host machine.
In FIG. 2A, computer host machines 200 and 201 are coupled through network 204. Network 204 provides network communications services, e.g., using TCP/IP, to support object requests between host machines. Host machines 200 and 201 contain, in their respective mass storage (e.g., a hard disk drive) 209 and 210, a full installation of binaries and other files for client.exe 205, library 206, ORB daemon.bin 207 and objects.bin 208. The software elements 205, 207 and 208 from mass storage 209 are executed by the central processing unit (CPU) in host machine 200 to provide active processes for client 211, ORB daemon 212 and objects/object servers 213, respectively. Similarly, the software elements 205, 207 and 208 from mass storage 210 are executed by the CPU in host machine 201 to provide active processes for client 214, ORB daemon 215 and objects/object servers 216, respectively.
In host machine 200, when client 211 wants to reference an object, client 211 sends an object request through local ORB daemon 212. ORB daemon 212 provides access to the object services of objects/object servers 213, as well as interacting with ORB daemon 215 over network 204 to provide further access to objects/object servers 216. Thus, client 211 is able to obtain services from local objects 213 and remote objects 216.
Similarly, in host machine 201, client 214 sends all object requests through ORB daemon 215. ORB daemon provides client 214 with access to local objects 216 and, through ORB daemon 213, with access to remote objects 213. Object services are thus shared through any number of host machines on the network.
Often, a host machine is used for forwarding local client requests to remote hosts. I.e., the local ORB daemon for the local host is used to forward object requests from the local client process to a remote ORB daemon on a remote host machine wherein the desired object services are provided. The local host is configured with a full support installation, such as library 206, ORB daemon.bin 207 and objects.bin 208. The ORB daemon.bin 207 does not provide any object service support. In addition, none of the other support object software is used. Only the software needed to support the client is used in this case. Therefore, the storage of full support software at the host machine is wasteful and unnecessary. Further, the administration of networked object software, including the handling of version updates, is unnecessarily complicated by the installation of unneeded networked object software. It is more efficient to store only the binary files necessary to support a pure client.
FIG. 2B is a block diagram of a network wherein host machine 201 contains a pure client, i.e., a client.exe binary file without further local support software. Host machine 201 stores client.exe 205 in mass storage 210. Client process 214, resulting from execution of client.exe 205 by the host machine""s CPU, operates without the benefit of a local ORB daemon process. In contrast, host machine 200 is configured as in FIG. 2A, with a full installation of networked object support software. Host machine 200 is therefore enabled to act as a server for object services, and also as a client. Host machine 200 contains the running processes for ORB daemon 212 and objects/object servers 213.
The configuration of FIG. 2B is efficient since it contains a software installation that provides only client support. Thus, only the binary file client.exe requires administration on host machine 201. There is no need to install and administer any other software since host machine 201 provides client capability alone. However, the configuration of host machine 201 does not provide any networked object support such as a local ORB daemon. Client process 214 must have some mechanism for locating a remote ORB daemon, such as ORB daemon 212 on host machine 200, in order to access object services. In the prior art, the client requires support from the user in order to access a remote ORB daemon. That is, the user (e.g., a person, such as a software developer, interacting with the client process via keyboard, mouse, display, etc.) must provide a reference or path to the remote ORB daemon. This requires that a user possess current information regarding network configurations.
Remote Access Protocol
In an X-windows environment, it is possible to assign host names to environmental variables to control, for example, where the display output of an X application will be displayed. This is performed by a user typing at a system prompt, xe2x80x9csetenv Display=[path]/[hostname]:0,xe2x80x9d where [path] is the physical path in the network leading to the desired host machine called xe2x80x9c[hostname].xe2x80x9d
Similarly, a user override value can be set in the NEO environment to specify a host machine in which a client process is to look for an ORB daemon. This is the mechanism by which a user may invoke a client process and successfully access remote object services without benefit of a local ORB daemon. However, this process requires that the user know beforehand the hostname for a host machine wherein an active ORB daemon process resides. There is no mechanism by which a pure client can locate a running ORB daemon without intervention from the user. This is inconvenient for the user and detracts from the transparency of client/server operations.
FIG. 3 is a flow diagram of the process of the prior art whereby a pure client is directed to a remote ORB daemon to access object services. As previously indicated, the process requires that the user determine where on the network an active ORB daemon is provided. This is typically done by contacting a network system administrator to inquire where a full installation of the networked objects software has been performed. The administrator then furnishes the hostname for the applicable host machine. Determining the needed hostname is step 300 in FIG. 3.
In step 301, the user sets the override path for the pure client using the hostname provided in step 300. In step 302, the user invokes, or launches, the client process (214) on the local host machine (201). When the client process has an object reference, in step 303, the client process looks for an active ORB daemon residing at the host machine specified with the user override value. A branching occurs at step 304 based on whether the ORB daemon is present at the user override location. If the user override value points to a host machine with an active ORB daemon, such as host machine 200 in FIG. 2B, in step 305, the client contacts the remote ORB daemon, and sends all object requests through the remote ORB daemon.
However, if an active ORB daemon is not present at the host machine specified by the user override value, e.g., the ORB daemon is not currently running or has been moved to another host machine, then in step 306, the client process attempts to contact a local ORB daemon. A branching occurs at step 307 based on whether a local ORB daemon exists. If there is a local ORB daemon running on the local host machine, in step 308, the client process sends an object request to the local ORB daemon. If, as is the case in FIG. 2B, there is no local ORB daemon process, an error is returned in step 309 to indicate that an ORB daemon is not available. From step 309, the process returns to step 300, where the user must find another suitable host machine.
The process of FIG. 3 is dependent for pure client support on the user and his administration-level knowledge of the network. If the user-supplied override value is not valid, i.e., does not point to a host with an active ORB daemon, then the client is unable to access object services. Thus, the process of FIG. 3 is error prone and difficult to use.
A method and apparatus for supporting a pure client is provided. In an embodiment of the invention, a client process is executing on a local host machine, whereas server software for supporting the client is physically stored on a remote host machine. The remote host machine also includes an active server process. The remote server software that supports the client is identified in the local host machine using an automatic, system generated reference, such as an NFS mount table entry. The mount table entry associated with the remote server software identifies the hostname of the remote host machine in which the remote server software is physically mounted. When the client process has a server request, the client process locates the remote server software entry in the mount table. A hostname specified in the mount table entry is used by the client process to contact the active server process at the remote host machine having that hostname. Thus, a pure client is able to locate and contact a remote server process, such as an ORB daemon without local ORB daemon support or user intervention.